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ABSTRACT 

A  key  element  in  the  anticipated  information  management  problem  on  a  naval 
platform  is  the  ability  to  combine  or  fuse  data,  not  only  as  a  volume-reducing  strategy,  but 
also  as  a  means  to  exploit  the  unique  combinations  of  data  that  may  be  available.  In  this 
regard,  the  Command  and  Control  Division  at  DREV  is  involved  in  multiple  R&D  activities 
in  the  field  of  local  area  Multi-Sensor  Data  Fusion  (MSDF)  for  naval  command  and  control 
afloat.  Many  different  approaches  to  MSDF  have  been  investigated  and  developed  recently 
in  response  to  the  ever-increasing  importance  of  the  subject.  However,  at  this  stage  of 
development,  no  standard  approach  is  generally  accepted  for  all  applications.  A  wide 
variety  of  techniques  have  been  proposed  for  many  diverse  applications,  and  the  system 
designer  must  choose  the  techniques  that  are  best  suited  to  a  specific  problem.  One  of  the 
best  tools  to  help  the  designer  with  such  a  choice  is  a  computer  simulation  for  proof-of- 
concept  purposes.  This  document  presents  an  overview  of  the  CASE_ATTI  (Concept 
Analysis  and  Simulation  Environment  for  Automatic  Target  Tracking  and  Identification) 
algorithm-level  simulation  testbed  that  has  been  developed  by  DREV  to  support  the 
theoretical  work.  CASE_ATTI  provides  the  highly  modular,  structured  and  flexible 
hardware/software  environment  necessary  to  study  and  compare  various  advanced  MSDF 
concepts  and  schemes  in  order  to  demonstrate  their  applicability,  feasibility  and 
performance.  The  document  also  discusses  the  use  of  CASE_ATTI  to  support  an  ongoing 
MSDF  performance  evaluation  study  in  the  context  of  the  Canadian  Patrol  Frigate. 


RESUME 

Un  element  fondamental  du  probleme  anticipe  de  la  gestion  de  l'information  sur  une 
plate-forme  navale  est  la  capacite  de  combiner  ou  de  fusionner  les  donnees,  non  seulement 
comme  stratdgie  de  reduction  du  volume  d'information  mais  aussi  comrae  moyen 
d'exploiter  les  combinaisons  uniques  de  donnees  qui  peuvent  etre  disponibles.  A  cet  egard, 
la  Division  du  commandement  et  controle  du  Centre  de  recherches  pour  la  defense, 
Valcartier  (CRDV)  participe  a  plusieurs  activites  de  R&D  dans  le  domaine  de  la  fusion 
locale  de  donnees  multi-capteurs  pour  le  commandement  et  controle  naval  au  large.  En 
rdponse  k  l'importance  croissante  de  la  fusion  de  donnees,  on  a  recemment  dtudie  et 
ddveloppe  maintes  fagons  d'aborder  cette  question.  Cependant,  a  ce  stade-ci  du 
developpement,  aucune  approche  standard  n'est  generalement  acceptee  pour  traiter  toutes 
les  applications.  C'est  pourquoi  on  a  propose  une  varidte  de  techniques  pour  differentes 
applications.  Le  concepteur  de  systbmes  doit  choisir  les  techniques  les  plus  appropriees  a 
un  probleme  donne.  Un  des  meilleurs  outils  pour  aider  le  concepteur  dans  ce  choix  est  une 
simulation  sur  ordinateur  pour  demontrer  les  concepts.  Ce  document  presente  une  vue 
d’ensemble  du  banc  d'essai  d’algorithmes  EACS_PIAC  (environnement  d’analyse  de 
concepts  et  de  simulation  pour  la  poursuite  et  l'identification  automatique  de  cibles)  qui  a 
6te  ddveloppe  au  CRDV  pour  appuyer  les  etudes  theoriques.  EACS_PIAC  procure 
l’environnement  materiel/logiciel  tres  modulaire,  structure  et  flexible  necessaire  pour  dtudier 
et  comparer  differents  concepts  et  plans  avances  de  fusion  de  donnees  de  capteurs  dans  le 
but  de  demontrer  leur  applicability,  leur  faisabilite  et  leur  performance.  Nous  discutons 
egalement  de  l'utilisation  d'EACS_PIAC  pour  appuyer  une  etude  en  cours  portant  sur 
revaluation  de  la  performance  de  la  fusion  de  donnees  provenant  de  plusieurs  capteurs 
pour  la  fregate  de  patrouille  canadienne. 
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EXECUTIVE  SUMMARY 

Current  Above  Water  Warfare  (AWW)  systems  afloat  are  largely  composed  of 
stand-alone  subsystems.  Until  recently,  there  has  been  a  tendency  for  various  AWW 
sensors  and  weapons  to  be  conceived,  developed  and  produced  in  isolation  from  each 
other.  These  components  are  only  to  be  brought  together  on  the  ship  and,  there, 
superficially  integrated.  However,  the  development  and/or  acquisition  of  advanced  AWW 
sensor  and  weapon  elements,  although  necessary,  are  not  sufficient  for  providing  the 
required  protection  of  ships  against  the  anticipated  future  threats.  The  simple  interfacing  of 
the  elements  is  not  enough  because  such  independent  AWW  components  are  seldom  used 
in  a  coordinated  manner.  This  typically  leads  to  a  confusing  and  time-late  decision 
environment  for  the  ship's  commander.  Hence,  the  effectiveness  of  the  AWW  system  is 
not  only  determined  by  the  capabilities  of  the  AWW  sensor  and  weapon  suites  alone,  but 
also  by  the  effectiveness  of  the  AWW  system  integration  which  must  focus  on  cooperative, 
synergistic  and  efficient  utilization  of  all  of  the  AWW  sensor  and  weapon  elements. 

In  this  regard,  the  Command  and  Control  Division  at  DREV  is  involved  in  multiple 
R&D  activities  in  the  field  of  local  area  Multi-Sensor  Data  Fusion  (MSDF)  for  naval 
command  and  control  afloat.  One  of  the  best  tools  to  support  these  activities,  and  help  the 
MSDF  designer  with  the  selection  of  techniques  that  are  best  suited  to  a  specific  problem,  is 
a  computer  simulation.  This  document  presents  an  overview  of  the  algorithm-level 
simulation  testbed  that  has  been  developed  by  DREV  to  support  the  MSDF  R&D.  It  also 
discusses  the  use  of  this  testbed  in  the  framework  of  an  ongoing  MSDF  performance 
evaluation  study  for  the  Canadian  Patrol  Frigate  (CPF).  The  results  of  this  study  are  of 
prime  importance  when  considering  the  mid-life  update  of  the  CPF. 

MSDF  comes  at  a  time  when,  potentially,  the  Canadian  Forces  will  have  to  do  more 
with  less  personnel.  As  the  size  of  the  Forces  diminishes,  the  role  of  those  who  remain 
"ever-vigilant"  increases  in  importance.  The  development  of  the  simulation  environment 
described  in  this  report  resulted  in  a  major  improvement  of  the  knowledge  base  at  DREV  in 
the  field  of  MSDF.  Indeed,  the  knowledge,  expertise  and  material  gained  as  a  result  of  this 
project  provide  DREV  with  the  opportunity  to  take  a  leading  role  in  the  evaluation  of 
current  and  future  MSDF  systems  for  the  Canadian  Forces.  With  this  project,  DREV  also 
increased  its  capacity  to  advise  the  Forces  in  the  selection  of  integrated  surveillance  and 
tracking  systems  suitable  to  fulfill  their  requirements,  and  in  the  optimization  of  the 
operation  of  these  systems  to  obtain  the  best  performance. 
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1.0  INTRODUCTION 

In  the  past  few  years,  a  lot  of  effort  within  the  C2  Division  at  DREV  has  been 
directed  towards  the  automation  of  C2  processes  for  managing  the  information  and 
allocating  the  resources  by  which  the  naval  commander  can  exercise  command  and  control 
in  actual  and  future  Above  Water  Warfare  (AWW)  scenarios.  An  appropriate  conceptual 
framework  (Ref.  1)  describing  the  C2  process  in  the  context  of  a  single  naval  platform  (or 
single  ship)  puts  in  perspective  three  critical  issues  for  the  evolution  of  naval  C2:  data 
fusion,  situation  assessment  and  resource  management. 

A  research  project  has  been  undertaken  by  the  Data  Fusion  group  to  investigate  in 
depth  issues  related  to  Multiple  Target  Tracking  and  Identification  using  Multiple  Dissimilar 
Sensors  (MDS/MTTI),  which  is  generally  referred  to  more  simply  as  Multi-Sensor  Data 
Fusion  (MSDF).  The  objective  of  this  project  is  to  analyze,  evaluate  and  develop  advanced 
techniques  to  automatically  produce  the  optimal  estimate  of  the  position,  kinematic 
behavior,  and  identification  of  all  objects  surrounding  a  single  ship,  mainly  through  the 
fusion  of  data  from  dissimilar  organic  sensors  (e.g.,  radar,  E-O,  ESM),  while  including 
inorganic  information  (e.g.,  data  coming  over  communication  links,  intelligence  reports, 
etc.).  The  use  of  the  latter  type  of  information  is  directed  towards  the  potential  enhancement 
of  the  performance  of  the  different  sensor  data  fusion  subprocesses.  The  end  result  of 
MSDF  (i.e.,  a  highly  reliable  computation  of  the  tactical  picture)  is  used  as  an  input  to  the 
subsequent,  higher  level  situation  assessment  and  threat  evaluation  C2  processes. 

An  overview  of  the  R&D  activities  involving  the  Data  Fusion  group  in  the  field  of 
local  area  MSDF  for  naval  command  and  control  afloat  (including  a  description  of  the 
fundamental  research  that  has  been  driven  by  DREV)  is  presented  in  a  separate  document 
(Ref.  1).  One  of  the  best  tools  to  support  these  activities,  and  help  the  MSDF  designer  with 
the  selection  of  techniques  that  are  best  suited  to  a  specific  problem,  is  a  computer 
simulation.  This  document  presents  an  overview  of  the  algorithm-level  simulation  testbed 
that  has  been  developed  by  DREV  to  support  the  MSDF  R&D  project. 

This  document  is  organized  as  follows.  Chapter  2  discusses  the  tool  sets  and  trial 
data  sets  that  are  available  for  supporting  research  activities  in  the  MSDF  domain.  A 
description  of  the  CASE_ATTI  (Concept  Analysis  and  Simulation  Environment  for 
Automatic  Target  Tracking  and  Identification)  algorithm-level  simulation  testbed  developed 
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at  DREV  is  given  in  Chapter  3.  CASE_ATTI  provides  the  highly  modular,  structured  and 
flexible  hardware/software  environment  necessary  to  study  and  compare  various  advanced 
MSDF  concepts  and  schemes  in  order  to  demonstrate  their  applicability,  feasibility  and 
performance. 

In  Chapter  4  we  discuss  how  CASE_ATTI  is  currently  being  used  to  support  the 
development  and  evaluation  of  advanced  sensor  data  fusion  concepts  in  the  context  of  the 
CPF. 


The  R&D  activities  described  in  this  document  were  performed  at  DREV  between 
1990  and  1994  under  PSC  12C,  Ship  Combat  System  Integration. 
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2.0  EXPERIMENTAL  DATA,  TESTBED  AND  SIMULATIONS 

Part  of  the  overall  MSDF  techniques  analysis,  development  and  evaluation  process 
involves  the  decision  regarding  the  approach  or  means  that  will  be  used  for  conducting 
these  research  activities  (Ref.  2).  A  characterization  of  the  overall  spectrum  of  possible 
tools  is  shown  in  Table  1 ,  adapted  from  Ref.  2.  This  broad  spectrum  ranges  from  using 
very  simple  computer  simulations  supporting  rigorous  mathematical  analyses,  to  actually 
testing  prototypes  during  live  military  exercises.  Generally,  as  is  depicted  in  Fig.  1,  also 
adapted  from  Ref.  2,  there  are  tradeoffs  in  selecting  one  approach  over  the  other.  The  most 
obvious  one  is  probably  the  level  of  operational  realism  obtained  versus  the  costs. 

The  ultimate  test  to  evaluate  the  military  value  of  a  prototype  would  be  to  use  it  in 
live  military  exercises.  Such  an  environment  provides  reasonably  high  fidelity  operational 
conditions  since  the  real-world  physics,  human,  equipment  and  tactics/doctrine  can  be 
taken  into  account.  However,  there  are  major  drawbacks  to  this  approach.  The  system 
designers  typically  cannot  have  full  control  of  the  events,  and  it  is  difficult  to  collect  the 
relevant  data.  In  particular,  precise  truth  data  that  are  needed  for  MSDF  performance 
evaluation  can  be  hard  to  obtain  in  real-world  tests;  these  are  however  readily  available  in 
computer  simulations.  The  latter  typically  constitutes  very  controlled  research  environments 
that  offer  a  high  level  of  convenience  and  flexibility  at  low  costs.  Unfortunately,  digital 
simulations  cannot  always  adequately  represent  complex  real-world  phenomena  and  human 
behavior.  Specialized  field  data  collection  campaigns  can  be  a  good  compromise  between 
these  two  extremes.  Indeed,  this  approach  is  often  used  to  validate  computer  simulations. 
However,  such  trial  activities  can  rapidly  become  very  costly. 

This  chapter  discusses  the  tool  sets  and  trial  data  sets  that  are  available  for 
supporting  the  research  activities  under  the  MSDF  project. 

2.1  Trial  Data 

Given  the  level  of  realism  that  they  provide  for  system  design  and  evaluation,  high- 
quality  trial  data  sets  are  a  goal  that  the  Canadian  MSDF  community  should  be  seeking. 
There  is  indeed  an  urgent  need  for  data  sets  from  real  sensors  and  targets,  even  though 
such  sensor-target  pairs  may  only  be  representative  for  a  specific  variety  of  applications.  To 
date,  however,  very  little  calibrated  and  simultaneously  collected  data  on  targets  of  interest 
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Toolset 

Characteristics 

Digital  Simulations 

•  Level  1:  Engineering  Models 

•  Level  2:  1  vs  N 

•  Level  3:  M  vs  N 
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TABLE  I  -  Generic  spectrum  of  analysis  /  modeling  /  evaluation  tools  (adapted  from  Ref.  2) 
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FIGURE  1  -  Tradeoffs  in  analysis  /  modeling  /  evaluation  approaches  (adapted  from  Ref.  2) 
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exists.  And  this  is  especially  true  for  the  case  of  dissimilar  sensors.  Only  a  few 
organizations,  almost  exclusively  located  in  the  US  or  Europe,  have  invested  in  the 
collection  of  such  trial  data.  Given  various  political  factors  and  the  cost  of  such  collection 
operations,  these  data  are  usually  very  sensitive  and  typically  become  (appropriately) 
proprietary.  As  a  result,  the  MSDF  designers  must  most  of  the  time  content  themselves 
with  trial  data  that  have  only  a  limited  relevance  to  MSDF. 

2.1.1  AN/SAR-8  Performance  Assessment  Trial  Data 

There  is  an  opportunity  in  Canada  to  evaluate  experimentally  the  performance  of 
dissimilar  sensor  data  fusion  by  analyzing  the  AN/SAR-8  land-based  trials  database 
presently  held  at  NETE  (Naval  Engineering  Test  Establishment)  in  Montreal.  This  database 
contains  radar  and  AN/SAR-8  (IRST)  data  with  time  stamp  that  were  recorded  on  a  variety 
of  air  targets  (Ref.  3).  A  considerable  effort  has  already  been  done  by  NETE  for 
preprocessing  the  data. 

There  are,  however,  a  number  of  drawbacks  to  using  this  trial  database  for  data 
fusion  purposes.  The  most  obvious  one  is  that  the  experiment  was  conducted  in  order  to 
evaluate  the  performance  of  the  AN/SAR-8  infrared  sensor,  not  to  study  or  validate  MSDF 
concepts.  The  radar  sensors  were  thus  used  only  to  help  find  the  targets  of  interest  (i.e.,  to 
establish  some  ground  truth  data  for  the  AN/SAR-8  evaluation).  Moreover,  these  radars  are 
not  the  ones  that  may  interest  the  Canadian  Navy. 

2.1.2  The  CPF  Performance  Monitoring  and  Analysis  System 

The  Canadian  Navy  has  long  recognized  the  need  for  a  shipboard  system  that  can 
gather  on-line,  real-time  data  during  surface-and-air  weapon  trials  (Ref.  4).  Indeed,  the 
need  for  a  tool  that  can  continuously  monitor  and  assess  the  combat  readiness  and 
performance  of  a  ship's  weapon  and  sensor  subsystems  has  never  been  greater.  The 
information  gathered  by  such  a  tool  would  serve  to  validate  combat  simulation  models 
whose  results  must  themselves  be  validated  against  live  data. 

For  the  CPF,  a  history  recording  (HR)  capability  was  incorporated  at  the  CCS 
level.  Unfortunately,  HR  captures  only  combat  system  data  which  has  already  been 
processed  by  the  CCS  software  modules.  Moreover,  the  in-depth  analysis  and  presentation 
of  the  HR  data  can  only  be  done  ashore,  rendering  a  quick  assessment  of  a  trial  impossible. 
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Although  some  weapon  and  sensor  subsystems  possess  limited  data  logging  and  reduction 
capabilities,  there  is  no  provision  for  synchronizing  data  collection  or  correlating  significant 
events  between  each  subsystem.  For  these  reasons,  a  CRAD-funded  prototype  surface- 
and-air  weapon  monitoring  and  analysis  system  was  developed  specifically  for  CPF 
acceptance  trials  and  future  combat  system  trials.  The  Performance  Monitoring  and 
Analysis  System,  or  PMAS  as  it  is  called,  comprises  separate  subsystems  for  data 
acquisition  and  recording  (DAR),  and  for  data  analysis  and  presentation  (DAP). 

The  CPF  combat  system  architecture  is  characterized  by  several  separate  processes 
exchanging  information  via  a  communication  network.  The  CPF  distributed  architecture 
utilizes  the  global  system  bus,  SHINPADS,  to  communicate  between  several  AN/UYK- 
505  computers  and  AN/UYQ-501  displays.  Furthermore,  each  AN/UYK-505  computer 
contains  dedicated  software  modules  that  handle  the  Naval  Tactical  Data  System  (NTDS) 
interfaces  to  the  off-the-shelf  sensor  and  weapon  subsystems.  The  major  components  of 
the  AWW  system  whose  interfaces  (NTDS  A,  B  and  D)  can  be  tapped  and  analyzed  by  the 
PMAS  include  the  Separate  Track  and  Illumination  Radar  (STIR)  control  console,  the  SPS- 
49  long-range  radar,  the  Sea  Giraffe  medium-range  radar  and  their  associated  CCS 
software  modules.  The  DAR  subsystem  of  PMAS  is  based  on  five  tap  units  which  provide 
a  transparent  passive  connection  to  the  interface  components  of  the  CPF  combat  system. 
These  tap  units  monitor  the  NTDS  interfaces  and,  upon  time  synchronization,  record  the 
message  traffic.  The  system  time,  stamped  on  all  tap  unit  recordings,  is  synchronized  to 
enable  post-trial  correlation  of  each  interface's  message  data.  The  tap  units  can  also  filter 
the  recorded  messages  to  remove  unwanted  and  periodic  non-changing  messages  before  the 
data  is  viewed  by  the  tap  unit  operator  or  transferred  to  the  DAP  subsystem  of  PMAS.  The 
latter  is  used  to  gather  data  from  all  interfaces  being  tapped  by  the  DAR  subsystem.  This 
voluminous  data  is  then  reduced,  converted  to  engineering  units  and  placed  into  a  relational 
database  from  which  it  can  be  extracted  for  report  generation. 

In  view  of  what  has  been  discussed  above,  it  seems  obvious  that  PMAS  could  be 
used  as  the  basic  means  supporting  a  specialized  field  data  collection  operation  dedicated  to 
the  investigation  of  MSDF  concepts  for  the  CPF.  The  PMAS  capability  to  acquire  and 
record  CPF  sensor  data,  including  CANEWS  ESM  data  (tests  have  been  run  at  the  Fleet 
Software  Support  Centre  where  NTDS  interfaces  are  used  by  the  CANEWS  software 
testing  facility),  could  be  used  for  that  purpose  during  military  exercises  involving  the 
CPF.  However,  despite  its  good  design  and  implementation,  PMAS  represents  only  the 
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tool  required  to  collect/analyze  sensor  data.  A  well  controlled  experiment  dedicated  to  the 
study  of  MSDF  issues  and  involving  humans,  equipment,  tactics/doctrine,  extended 
engagements,  etc.,  still  remains  to  be  designed  and  set  up.  This  would  require  a 
tremendous  amount  of  preparation  and  may  result  in  a  very  costly  operation.  No  concrete 
steps  have  been  taken  so  far  in  this  direction. 

2.2  Testbeds  and  Simulations 

The  extremely  limited  availability  of  trial  data  to  support  algorithm  development  and 
MSDF  system  prototypes  represents  a  serious  detriment  to  the  Canadian  MSDF 
community.  Many  research  programs  whose  focus  is  on  MSDF  algorithm  analysis  and 
development,  such  as  the  one  of  interest  in  this  document,  cannot  afford  to  incur  additional 
costs  of  data  collection  for  the  purpose  of  demonstrating  algorithms  with  real  data. 
Alternatives  to  this  situation  include  artificially  synthesizing  multi-sensor  data  from 
individual  sensor  data  collected  under  non-standard  conditions  (not  easy  to  do  in  a 
convincing  manner),  or  to  employ  high-fidelity  sensor  and  phenomenological  simulators. 
This  last  option  has  been  retained  for  the  MSDF  project  at  DREV  since,  most  of  the  time, 
representative  simulated  data  may  be  sufficient  to  verify  or  validate  MSDF  concepts. 

2.2.1  Parametric-Level  Testbeds 

Over  the  last  several  years,  the  defence  community  has  built  up  a  testbed  capability 
for  studying  various  components  of  the  MSDF  process  (Ref.  2).  In  general  these  testbeds 
have  been  associated  with  a  particular  program  and  its  range  of  problems  and,  except  for  a 
few  instances,  they  have  permitted  parametric-level  but  not  algorithm-level 
experimentation.  That  is,  these  testbeds,  as  software  systems,  were  built  from  "point" 
designs  for  a  given  application  wherein  normal  control  parameters  could  be  altered  to  study 
attendant  effects,  but  these  testbeds  could  not  (at  least  easily)  permit  replacement  of  such 
components  as  a  complete  tracking  algorithm. 

The  small-scale  computer  simulation  model  developed  under  the  DIRP  by 
Thomson-CSF  Systems  Canada  (Refs.  5-7)  is  a  good  example  of  such  a  parametric-level 
testbed.  This  PC  simulation  environment  has  been  specifically  implemented  to  compare  the 
tracking  performance  of  four  types  of  MSDF  architecture  for  a  given  multiple  target 
scenario,  and  quantify  the  advantages  and  drawbacks  of  each  approach.  The  user  can 
define  and  save  the  true  target  trajectories  and  the  scenario  to  be  used  in  the  simulation.  He 


P151678.PDF  [Page:  19  of  59] 


UNCLASSIFIED 

9 


can  also  specify  whether  the  radar  measurements  will  be  created  for  the  current  run  or  will 
be  read  from  an  existing  disk  file.  The  user  can  choose  the  type  of  tracking  architecture  to 
be  simulated,  but  cannot  modify  the  actual  implementation  of  this  architecture;  the  tracking 
algorithms  are  hard-coded.  The  flexibility  of  this  testbed  is  thus  limited  to  the  variation  of  a 
few  scenario  parameters  such  as  the  target/ownship  geometry. 

2.2.2  Algorithm-Level  Testbeds 

High-fidelity  simulation  environments  that  permit  algorithm-level  test  and 
replacement  are  required  for  the  investigation  of  advanced,  state-of-the-art  MSDF 
algorithms  and  techniques.  Recently,  some  new  testbed  designs  are  moving  in  this 
direction.  Two  examples  are  the  "Multisensor,  Multitarget  Data  Fusion  Testbed"  developed 
by  Rome  Lab  (Ref.  8)  and  the  "Integrated  Testbed"  developed  within  the  Command  and 
Information  Systems  Division  of  Deutsche  Aerospace  in  Germany  (Ref.  9).  However,  both 
of  these  environments  are  not  tailored  to  naval  applications.  Two  other  of  these  new  tools 
are  the  MSDF  demonstration  model  currently  being  developed  under  the  Defence  Industrial 
Research  Program  (DIRP)  by  Paramax  Systems  Canada  in  Montreal  (Refs.  10-13),  and  the 
Concept  Analysis  and  Simulation  Environment  for  Automatic  Target  Tracking  and 
Identification  (CASE_ATTI)  system  developed  by  DREV  (Refs.  14-18).  Both  of  these 
testbeds  are  further  discussed  below  (the  description  of  CASE_ATTI  constitutes  Chap.  3). 

2.3  Real-Time  MSDF  Demonstration  Model  at  Paramax 

Under  contract  with  DREY,  as  discussed  in  Ref.  1,  Paramax  Systems  Canada 
analyzed  the  feasibility  of  implementing  an  MSDF  function  for  the  current  sensor  suite  of 
the  CPF,  within  the  CPF  operational  land-based  test  facility  at  Paramax  in  Montreal  (i.e., 
originally  the  Combat  Systems  Test  and  Support  Facility  (CSTSF),  recently  renamed  as 
Software  Development  Test  Facility  (SDTF))  (Ref.  19).  As  a  follow-up  to  this  feasibility 
study,  Paramax  submitted  a  DIRP  proposal  entitled  "Implementation  of  Sensor-Level  Hard 
Fusion  for  CSTSF  Sensors"  (Ref.  10),  with  DREV  as  scientific  advisor. 

One  objective  of  this  R&D  activity  is  to  establish  a  facility  (or  demonstrator)  in  the 
CSTSF/SDTF  real-time  naval  CCS  to  use  the  data  provided  by  the  current  sensor  suite  of 
the  CPF  for  MSDF  purposes.  Given  that  it  is  developed  within  the  CPF  operational  land- 
based  test  facility,  this  algorithm-level  MSDF  demonstrator  is  provided  with  a  level  of 
realism  with  respect  to  the  CPF  that  can  hardly  be  matched  by  any  other  simulation 
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environments.  It  will  provide  a  capability  to  demonstrate  and  quantitatively  measure  the 
CCS  performance  with  and  without  MSDF,  using  the  same  simulation  environment  and 
real-time  operational  scenarios  that  were  used  for  the  development  of  the  CPF  CCS 
software. 

However,  as  was  previously  discussed  in  the  beginning  of  this  chapter,  there  are 
always  tradeoffs  to  be  made  between  the  level  of  operational  realism  of  a  testbed  and  other 
factors  such  as  costs  or  flexibility.  For  example,  the  software  design  strategy  for  the 
development  of  the  MSDF  system  demonstration  model  is  to  ensure  minimal  changes  to 
CPF  CCS.  The  only  CCS  modifications  are  to  sensor  interface  modules  which  have  to 
broadcast  sensor  data  as  soon  as  received  with  no  impact  on  CCS  operations.  On  one  hand, 
this  guarantees  that  the  performance  changes  are  only  due  to  the  incorporation  of  MSDF. 
On  the  other  hand  however,  this  design  strategy  was  imposed  by  the  high  costs  (and  other 
political  and  operational  constraints)  associated  with  any  modification  to  the  CSTSF/SDTF 
environment.  This  may  become  very  restrictive  in  terms  of  research  flexibility.  For 
example,  the  MSDF  architecture  that  was  selected  for  implementation  and  investigation 
within  the  current  testbed  is  the  sensor-level  architecture,  although  one  can  prove  this  is  not 
the  most  optimal  one.  This  is  because  the  current  sensors  on  the  CPF  have  their  own 
Automatic  Detection  and  Tracking  (ADT)  subsystems  so  that  these  sensors  provide  tracks 
to  the  CCS.  The  study  of  the  central-level  architecture  would  necessitate  serious 
modifications  to  the  CSTSF/SDTF  (or  even  worse  to  the  sensors  themselves)  in  order  to 
have  access  to  contact  data  from  the  sensors;  these  modifications  could  be  relatively  costly. 

Because  tracking  techniques  implemented  in  the  current  sensors  of  the  CPF  are  very 
limited  when  compared  with  more  advanced  algorithms  that  can  be  found  in  the  literature, 
the  MSDF  techniques  that  have  been  selected  for  implementation  in  the  current  testbed  are 
also  very  simple.  Since  the  MSDF  demonstrator  design  has  great  potential  for  growth, 
more  sophisticated  MSDF  techniques  and  algorithms  could  be  implemented  and  studied;  in 
that  sense  the  demonstrator  is  an  algorithm-level  testbed.  However,  to  take  full  advantage 
of  it,  costly  modifications  to  the  CSTSF/SDTF  simulation  environment  would  again  be 
required. 

Other  drawbacks  associated  with  this  testbed  are  the  use  of  Ada  (limiting  the 
flexibility)  for  the  fusion  software  and  the  lack  of  access  to  ground  truth  data  for  on-line 
performance  evaluation.  Nevertheless,  despite  its  associated  constraints,  the  real-time 
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MSDF  demonstration  model  developed  by  Paramax  remains  a  highly  valuable  tool  that  is 
expected  to  play  a  major  role  in  the  implementation  of  an  MSDF  capability  onboard  a  real 
CPF  at  sea. 


3.0  CASE_ATTI  ALGORITHM-LEVEL  TESTBED 

An  important  R&D  activity  undertaken  by  the  C2  Division  at  DREV  addresses  the 
MSDF  critical  issue  for  the  evolution  of  naval  C2  within  the  Canadian  Forces.  Within  this 
activity,  an  algorithm-level  testbed  has  been  developed  (and  is  being  enhanced  on  a  regular 
and  progressive  basis)  for  proof-of-concept  purposes.  A  description  of  this  testbed,  called 
Concept  Analysis  and  Simulation  Environment  for  Automatic  Target  Tracking  and 
Identification  (CASE_ATTI),  is  given  in  this  chapter. 

3.1  Evolution 

Figure  2  illustrates  the  evolution  of  the  CASE_ATTI  system.  DREV  has  long 
recognized  the  fact  that  one  of  the  best  tools  to  help  a  designer  in  evaluating  a  target 
tracking  solution  is  a  software  testbed  (Ref.  20).  The  development  of  a  simulation 
environment  was  thus  undertaken  in  1990  and  a  first  prototype  with  limited  capabilities  was 
produced.  This  prototype  is  a  Single  Sensor/Multiple  Target  Tracking  (SS/MTT)  simulation 
environment  which  is  fully  described  in  Ref.  21.  The  prototype  is  limited  because  it 
supports  only  single-sensor  scenarios  and  it  does  not  include  the  target  identification 
process.  Despite  these  limitations,  this  environment  can  be  used  to  investigate  advanced 
SS/MTT  concepts.  Indeed,  it  has  been  successfully  used  in  a  joint  study  with  the  research 
group  on  data  fusion  at  the  Royal  Military  College  of  Canada  (RMCC)  to  investigate  the 
applicability  of  expert  systems  to  help  in  the  management  and  display  of  the  hypothesis  tree 
of  the  Multiple  Hypothesis  Tracking  (MHT)  algorithm  (Refs.  22-23). 

During  the  second  half  of  the  80s,  RMCC  developed  disparate,  non-reusable  pieces 
of  software  to  fulfill  the  requirements  of  DREV's  contracts  on  Kalman  filtering  concepts. 
In  order  to  study  more  complex  tracking  problems,  RMCC  evolved  their  software  to  an 
SS/STT  simulation.  At  the  same  time,  a  SS/MTT  simulation  environment  was  being 
developed  at  DREV.  To  avoid  duplication,  a  new  project  was  then  defined  by  DREV  to 
develop  a  high  quality  simulation  environment  specifically  dedicated  to  MSDF  studies.  As  a 
result,  RMCC  was  tasked  by  DREV  at  the  beginning  of  the  90s  to  undertake  the 
development  of  CASE_ATTI. 
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The  primary  requirement  for  this  development  activity  was  to  provide  DREV  with 
the  highly  modular,  structured  and  flexible  hardware/software  environment  necessary  to 
study  and  compare  various  advanced  MSDF  concepts  and  schemes  in  order  to  demonstrate 
their  applicability,  feasibility  and  performance.  This  requirement  yielded  the  first  true 
prototype  of  the  CASE_ATTI  system  (Ref.  14).  It  was  immediately  followed  by  a  multi¬ 
sensor  version  including  target  attribute  fusion  (Refs.  15-18).  This  new  environment 
exploits  the  recent  developments  in  the  software  engineering  domain  (e.g.,  object-oriented 
programming,  advanced  software  development  tools,  advanced  graphical  user  interface 
concepts  and  building  tools,  etc.),  and  the  availability  of  more  powerful  computer 
platforms.  The  following  sections  provide  the  reader  with  some  understanding  of  how  the 
CASE_ATTI  system  is  designed  and  how  the  tool  can  be  used  to  aid  a  designer  in 
evaluating  MSDF  algorithms  and  techniques.  A  more  complete  description  can  be  found  in 
Refs.  14-18. 

3 . 2  Design  Strategy 

Several  criteria  must  be  met  when  developing  such  a  MSDF  testbed.  It  must  be 
modular  to  allow  for  flexibility  in  the  testing  of  various  configurations  and  to  allow  for  easy 
alterations  or  customizing  in  the  future.  The  design  must  allow  the  users  to  easily  develop 
and  incorporate  their  own  tracking  algorithms,  sensor  models,  and  analysis  tools.  It  must 
provide  realistic  sensor  data  to  the  algorithms,  taking  into  consideration  such  items  as 
environmental  conditions  (ultimately,  the  ability  to  utilize  true  sensor  data  would  remove 
any  uncertainty  in  the  results  of  the  tracking  on  artificial  sensor  data).  In  addition,  the 
testbed  must  present  the  results  to  the  user  in  a  useful  and  manageable  way.  The  user  must 
be  able  to  animate  the  selected  scenario,  to  view  the  results  of  the  algorithms  while 
tracking,  to  select  statistics  and  have  them  presented  in  an  intuitive  manner.  It  must  also  aid 
the  user  in  designing  an  experiment.  When  creating  a  scenario,  the  user  must  be  able  to 
easily  configure  the  sensors,  the  platforms  on  which  the  sensors  are  stationed,  the  targets 
and  their  attributes,  the  trajectories  of  the  targets,  as  well  as  the  MSDF  algorithms. 
CASE_ATTI  adheres  to  all  of  the  above  criteria. 

The  modularity,  flexibility,  efficiency  and  speed  of  the  CASE_ATTI  system  are 
highly  dependent  on  the  selected  hardware  platform  and  software  design.  The  CASE_ATTI 
testbed  has  been  implemented  on  an  HP/ Apollo  9000,  series  700  workstation.  However, 
the  design  has  the  capabilities  of  utilizing  multiple  computers  across  a  Local  Area  Network 
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(LAN).  The  design  criteria  discussed  above  and  portability  requirements  dictated  to  a  large 
extent  the  software  platform  that  has  been  employed.  The  present  software  platform, 
illustrated  in  Fig.  3,  consists  of  UNIX  (HP-UX),  XWindows  for  the  user  interface, 
PHIGS  for  the  graphics,  and  C++/C. 

The  ability  of  the  system  to  meet  its  objectives  is  largely  based  on  its  object-oriented 
(OO)  design.  Such  an  algorithm-level  software  testbed  for  MSDF  is  a  very  complex 
system.  The  OO  paradigm  has  been  utilized  to  decompose  complexity  into  manageable 
objects.  This  ability  to  present  different  levels  of  abstraction  provides  a  better  presentation 
and  understanding  of  the  problem  to  different  users  (Ref.  24).  The  simulation  is  more 
intuitive  and  easier  to  understand  when  it  is  described  as  objects.  The  C++  language  was 
used  since  it  supports  the  object-oriented  paradigm.  It  utilizes  data  abstraction, 
encapsulation,  hierarchies,  modularity,  polymorphism  and  concurrency.  C++  is  also 
efficient  and  allows  for  the  inclusion  of  algorithms  that  have  already  been  developed  in  the 
C language. 

3 . 3  Global  Structure 

The  CASE_ATTI  testbed  has  been  divided  into  four  major  sub-blocks.  This 
division  simplifies  the  problem  both  conceptually  and  technically.  Figure  4  shows  a  simple 
block  diagram  representation  of  these  main  modules.  For  any  MSDF  system  simulation, 
the  scenario  configuration  is  handled  by  the  simulation  manager,  the  generation  of  sensor 
data  is  handled  by  the  sensor  module,  the  MSDF  architecture  is  simulated  within  the 
tracking  module,  and  the  assessment  of  the  results  is  provided  by  the  data  extraction, 
visualization  and  analysis  module.  Each  module  is  a  separate  process  with  a  means  of 
communicating  with  the  other  processes.  This  independence  between  modules  allows  the 
simulation  to  be  divided  amongst  several  computers  on  a  network.  Each  module  is  itself 
broken  into  blocks  which  account  for  the  modules  flexibility.  To  gain  better  understanding 
of  the  testbed,  further  elaboration  of  these  modules  is  given  in  the  following  sections. 

3.4  Sensor  Data  Generation  Module 

As  illustrated  in  Fig.  5,  a  typical  simulation  scenario  consists  of  platforms  (e.g., 
ships)  with  sensors,  and  targets.  The  platforms  can  be  stationary  or  moving  along  given 
paths.  One  or  more  potentially-dissimilar  sensors  (such  as  radar,  infrared,  ESM,  etc.)  can 
be  assigned  to  each  platform.  Targets  are  created  with  defined  attributes  and  trajectories. 
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FIGURE  3  -  CASE_ATTI  software  platform 
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FIGURE  5  -  Typical  scenario 
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FIGURE  6  -  Sensor  data  generation  scenario  hierarchy 
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The  scenario  also  allows  for  the  selection  of  environmental  conditions  that  may  affect  the 
various  sensor  measurements. 

The  sensor  data  generation  scenario  hierarchy  implemented  in  the  CASE_ATTI 
testbed  is  displayed  in  Fig.  6.  Lists  of  platforms,  sensors,  and  targets  must  be  provided  by 
the  user.  It  is  worth  noting  that  any  given  platform  is  considered  as  a  target  for  the  other 
platforms.  A  trajectory  must  be  specified  for  each  target  (and  platform),  and  a  search 
volume  must  be  specified  for  each  sensor.  All  scenarios  have  the  same  basic  structure. 

The  sensor  module  is  responsible  for  providing  realistic  measurement  data  to  the 
tracking  algorithms.  Given  a  user-defined  scenario  as  described  above,  it  generates  true 
target  positions  and  measured  target  positions,  which  are  subsequently  made  available  to 
the  tracking  module.  The  sensor  module  is  built  on  several  levels  of  abstraction,  each 
abstraction  providing  new  details  and  perspective  while  at  the  same  time  hiding  unwanted 
details  for  the  next  level  (Refs.  15-16).  As  shown  in  Fig.  7,  it  is  composed  of  several 
objects,  the  main  ones  being  platform  controller,  platform,  sensor  and  target  container.  The 
remainder  of  this  section  briefly  describes  these  objects  and  their  interaction  to  produce  the 
required  data  for  the  tracking  module. 

The  platform  controller  can  be  thought  of  as  a  hub  that  is  responsible  for  collecting 
information  from  the  various  platforms,  and  for  organizing  this  information  for  distribution 
either  to  the  tracking  or  to  the  graphics  display  modules.  The  platform  controller's 
responsibilities  are  thus  to  create  and  initialize  (or  configure)  each  platform  in  the  scenario 
and  to  manage  these  platforms  after  each  configuration.  The  latter  involves  updating  each 
platform  and  requesting  the  correct  platform  for  measurements.  At  this  highest  level  of 
abstraction  the  platform  controller  hides  the  details  of  sensor  simulation  from  the 
programmer.  The  programmer  knows  there  is  an  object  that  controls  the  platforms  in  the 
scenario  and  that  this  object  will  return  measurements,  but  how  these  measurements  are 
generated  is  unknown  to  his  perspective. 

All  sensors  are  mounted  on  some  type  of  platform  that  can  be  moving  or  be 
stationary.  A  platform  can  also  be  underwater,  on  the  surface  or  airborne.  Each  platform 
must  react  to  requests  from  the  platform  controller.  Typical  requests  are  to  advance  to  the 
next  event  time  and  to  obtain  from  the  platform  its  location,  the  type  of  sensors  assigned  to 
it,  and  a  list  of  measurements.  This  is  the  second  level  of  abstraction.  The  details  of 
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FIGURE  7  -  Sensor  module  object  communication  structure 


FIGURE  8  -  An  example  of  a  multi-tiered  generalized  tracker 
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configuring  and  positioning  the  sensors,  and  the  method  of  generating  the  measurements, 
are  hidden  from  the  platform  controller. 

At  the  next  level  of  abstraction,  the  sensor  object  represents  the  specific  type  of 
sensor  that  is  being  modeled.  As  illustrated  in  Fig.  7,  the  sensor  object  collaborates  with 
several  other  objects  to  create  the  required  behavior.  Collaboration  occurs  with  the  target 
container,  false  alarm,  and  search  volume  objects  in  producing  the  required  measurements. 
The  target  container  manages  all  targets  in  the  simulation,  and  all  requests  to  targets  must 
pass  through  this  class.  The  target  object  is  an  abstraction  of  a  real-world  object  that  can  be 
viewed  by  a  sensor.  For  example,  a  target  may  be  a  plane,  a  ship,  a  missile,  a  bird,  etc. 
One  of  the  main  properties  associated  with  a  target  is  its  trajectory. 

The  sensor  object  has  to  respond  to  requests  from  the  platform  for  measurements, 
next  time  update,  and  location  of  the  sensor.  Since  a  platform  may  contain  several 
dissimilar  sensors,  it  is  important  for  reuse  and  extensibility  that  a  common  interface  be 
utilized  for  each  sensor.  This  is  easily  performed  in  the  object-oriented  language  of  C++, 
which  supports  single  and  multiple  inheritance,  since  the  user  is  free  to  reuse  any  level  of 
abstraction.  A  generic  sensor  class  has  been  defined;  it  can  be  represented  as  a  tree  structure 
with  various  specialized  sensors  extending  from  it.  Any  new  sensor  model  is  derived  from 
this  generic  base  sensor.  This  greatly  simplifies  the  development  of  such  a  new  sensor 
component  since  each  specialization  of  the  sensor,  be  it  an  infrared,  a  radar  or  a  data  file, 
must  inherit  this  common  interface  to  the  platform.  As  a  result,  each  sensor  can  have  a 
completely  different  representation  behind  this  interface,  and  other  sensor  models 
previously  derived  from  this  base  sensor  would  not  be  altered  by  the  addition  of  a  new 
model.  Utilizing  this  inheritance  feature  limits  the  number  of  alterations  to  existing  code  and 
thus  aids  in  maintaining  the  integrity  of  the  existing  system. 

Timing  is  an  important  issue  for  the  sensor  data  generation  process.  The  procedure 
for  obtaining  measurements  is  performed  in  two  steps.  The  first  one  is  to  advance  the 
simulation  clock,  that  is,  to  select  the  next  platform  or  sensor  to  be  requested  for 
measurements.  The  second  step  is  to  request  these  objects  for  measurements.  The  platform 
controller  initiates  a  clock-advance  by  sending  an  update  message  to  the  platform  that  has 
produced  the  last  set  of  measurements.  This  platform  in  turn  requests  the  sector  time  for  the 
sensor  that  produced  the  measurements  for  the  platform.  The  sector  time  will  determine 
when  the  sensor  will  next  produce  measurements.  The  platform  uses  this  time  to  order  its 
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sensors  by  next  event  (i.e.,  all  sensors  are  ordered  in  a  queue  with  the  sensor  to  produce 
measurements  next  at  the  front  of  the  queue).  The  platform  then  updates  the  time  it  will  next 
produce  measurements  and  returns  this  time  to  the  platform  controller  object  which  orders 
the  platforms  by  next  event.  When  control  has  returned  to  the  platform  controller  object,  the 
sensor  module  has  completed  the  clock-advance.  The  objects  are  now  awaiting  the  second 
step,  which  is  the  request  for  measurements.  It  is  initiated  by  the  main  program  of  the 
sensor  module,  and  is  directed  to  the  platform  controller  which  will  then  request  the 
appropriate  platform  to  produce  measurements.  This  request  is  taken  from  the  platform  and 
handed  to  the  appropriate  sensor,  which  is  stationed  on  the  platform.  The  sensor  must 
produce  the  required  measurements. 

The  types  of  sensors  that  are  currently  inherited  from  the  generic  sensor  (or  base 
class)  are  radar,  infrared,  data,  and  artificial.  The  radar  class  represents  a  surveillance  radar 
sensor  whose  model  has  been  developed  at  DREV.  This  model  is  specifically  dedicated  to 
sensor  integration  and  data  fusion  studies  (Ref.  25).  The  aim  of  the  design  was  to  propose 
the  highest  possible  level  of  radar  simulation  while  ensuring  that  the  major  perturbing 
effects  on  sensor  data  fusion  were  adequately  represented.  In  the  model  derivation,  the 
characteristics  of  the  radars  to  be  installed  on  CPFs  have  been  used  as  a  reference. 

The  infrared  model  works  in  a  similar  fashion  as  the  radar  model.  However,  the 
detection  computation  is  based  on  calculating  the  radiance  contrast  between  a  target  and  its 
background  (Ref.  26). 

The  class  artificial  represents  a  simplified,  academic-type  sensor.  This  type  of 
sensor  does  not  attempt  to  reproduce  accurately  the  behavior  of  a  real  sensor.  However,  it 
provides  sufficient  information  to  test  the  tracking  algorithms.  It  is  also  quicker  to 
implement,  and  gives  the  user  a  greater  flexibility.  The  detection  qnd  false  alarm 
probabilities  are  both  fixed  to  values  set  by  the  user.  One  can  also  select  which  target 
parameters  will  be  measured  by  the  sensor.  A  typical  example  of  an  artificial  sensor  is  a 
surveillance  radar  with  an  elevation  measurement  in  addition  to  the  range  and  bearing 
measurements. 

The  class  data  implements  the  mechanism  by  which  externally  generated  sensor  data 
(i.e.,  real  or  simulated,  live  or  recorded  sensor  data  generated  outside  of  CASE_ATTI)  can 
be  incorporated  into  the  CASE_ATTI  environment  in  order  to  feed  the  platform  object.  The 
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complexity  of  the  measurement  generation  process  for  this  sensor  data  is  hidden  or 
encapsulated  within  the  class  data.  As  a  typical  example,  stimulation  and  simulation 
softwares  of  an  ESM-type  sensor  (CANEWS  like)  are  already  available  from  the  Canadian 
industry.  They  could  be  used  to  produce  ESM  measurement  outputs  for  specified  threat 
scenarios.  The  resulting  ESM  data  would  then  be  integrated  into  the  CASE_ATTI  system, 
through  the  class  data,  to  be  used  jointly  with  other  sensor  data  (generated  within 
CASE_ATTI  for  exactly  the  same  scenarios). 

3.5  Tracking  Module 

The  ultimate  CASE_ATTI  system,  as  previously  mentioned,  must  be  a  highly 
flexible  simulation  environment  providing  the  algorithm-level  test  and  replacement 
capability  required  for  the  investigation  of  advanced,  state-of-the-art  MSDF  algorithms  and 
techniques.  As  such,  the  tracking  module  must  adapt  to  any  type  of  tracking  architecture  for 
any  scenario.  Its  design  must  have  the  capability  of  simulating  a  sensor-level,  central-level 
or  hybrid  tracking  architecture  as  required  (Refs.  20,  27).  The  inheritance  mechanism  and  a 
list  implementation  provide  the  flexibility  to  implement  these  types  of  architecture.  As  a 
result,  the  current  tracking  module  supports  a  wide  variety  of  tracker  architecture  types, 
varying  from  a  simple  single  sensor  tracker  to  an  arbitrarily  complex  hierarchical  multiple 
sensor  topology  such  as  the  one  illustrated  in  Fig.  8. 

The  object-oriented  approach  also  facilitates  the  inclusion  of  new  tracking 
algorithms  into  the  existing  tracking  module  (Refs.  14-17).  At  the  top  level  of  abstraction 
within  this  module  is  the  class  Trackerjist  that  contains  a  list  of  individual  trackers,  a 
description  of  the  connection  tree  between  the  sensors  and  trackers  along  with  tracker-to- 
tracker  connections,  and  finally,  a  set  of  common  tracker  initialization  parameters.  Each 
tracker  contains  gating,  association,  assignment  and  filtering  algorithms  for  incorporating 
new  input  information  into  existing  internal  tracks.  Trackers  within  a  Tracker_list  are 
derived  from  a  common  base  class,  Tracker_object.  The  underlying  structure  of  the 
individual  trackers  is  hidden  from  the  Trackerjist.  The  trackers  within  a  Trackerjist  are 
activated  upon  passing  an  input  message  with  the  appropriate  measurements  or  tracks  to  the 
tracker.  New  trackers  can  be  derived  from  a  Tracker_object  and  added  to  the  existing 
Trackerjist  without  having  to  alter  the  existing  tracker  classes,  thereby  providing 
considerable  flexibility  and  consistency. 
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At  the  start  of  the  simulation,  the  Trackerjist  reads  in  an  initialization/configuration 
file  for  the  user  defined  tracking  architecture.  This  file  contains  a  list  of  the  required 
trackers  to  be  created,  common  initialization  parameters,  and  the  network  connections. 
Once  configured,  a  Trackerjist  simply  ensures  that  data  is  forwarded  to  the  appropriate 
destination  in  the  correct  order. 

The  tracking  module  supports  depth  control  and  event  lists  to  handle  an  arbitrarily 
large  and  complex  network  of  trackers.  The  depth  parameter  specifies  the  dependency 
between  trackers.  For  example,  consider  the  tracker  illustrated  in  Fig.  8  of  depth  four.  The 
Tracker_list  passes  sensor  data  reports  to  the  appropriate  trackers,  and  the  trackers,  in  turn, 
create  copies  of  these  reports  and  insert  events  on  the  Tracker Jist's  event  list, 
accommodating  ordering  due  to  time  and  depth.  Upon  the  arrival  of  a  sensor  data  report 
with  a  time  tag  greater  than  that  of  the  head  event,  the  Trackerjist  stops  collecting  sensory 
input  and  starts  processing  the  trackers  listed  in  the  event  list  beginning  with  the  head 
event.  As  a  result,  the  Trackerjist  processes  the  trackers  with  a  lower  depth  first  and  relays 
the  resultant  output  data  to  the  trackers  of  higher  levels  during  the  present  scan.  As  new 
tracks  are  received  by  a  tracker  from  a  lower  depth  tracker,  an  additional  event  is  inserted 
on  the  master  event  list.  Any  paths  which  pass  data  from  a  higher  depth  tracker  to  one  with 
a  lower  depth  are  treated  exclusively  as  feedback  and  are  handled  during  the  next 
measurement  scan. 

The  tracking  module  can  output  data  from  any  one  of  the  trackers  within  the 
network  to  either  the  graphics/analysis  module  or  a  file.  This  feature  allows  an  operator  to 
examine  the  performance  of  any  tracker  within  a  potentially  large  and  complex  network  of 
trackers.  The  tracking  module  can  be  executed  on  one  or  more  machines.  If  all  the  trackers 
are  run  on  a  single  machine,  they  will  all  co-exist  as  a  single  process  to  maximize 
efficiency.  Alternatively,  the  tracking  module  offers  the  capability  to  employ  additional 
computational  resources  over  a  network  if  available.  For  this  case,  the  trackers  are  executed 
as  separate  processes,  ideally  one  process  per  machine.  The  specifications  for  the 
distribution  of  the  Tracker_objects  is  provided  in  the  initialization/configuration  file.  The 
remote  process  handler  is  implemented  at  the  base  class  level  to  standardize  the 
communications  interface  between  the  individual  trackers. 
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The  sensor-level  trackers  currently  implemented  include: 

1 .  'Multiple-Hypothesis  Tracker  (MHT) 

2.  Track-Split  filter 

3 .  Nearest-Neighbor  type  trackers  (both  Munkres-based  and  optimal) 

4.  (Joint)  Probabilistic  Data  Association  filter  (JPDA/PDA) 

The  MHT  implementation  is  capable  of  handling  multiple  simultaneous  reports  from 
different  sensors;  the  other  trackers  are  capable  of  handling  single  sensor  reports  at  a  time. 
A  global  track  fuser  using  a  version  of  the  MHT  tracker  for  assignment  has  also  been 
provided  to  fuse  the  sensor-level  tracks  to  form  global  tracks.  In  addition,  feedback  of 
these  global  tracks  to  the  local  sensor-level  trackers  is  allowed.  Current  efforts  include 
provisions  for  advanced  track  management  schemes  such  as  a  Hough-Transform  based 
track  initiator  tracker,  and  support  for  configurations  including  both  active  and  passive 
sensors. 

3.6  Data  Extraction,  Visualization  and  Analysis  Module 

Ultimately,  the  performance  of  MSDF  algorithms  is  judged  by  the  success  (or  lack 
thereof)  of  the  mission  they  support.  However,  such  a  global  performance  assessment  is 
not  appropriate  during  MSDF  system  development.  With  a  complex  computer  simulation  of 
a  MSDF  system  comprised  of  many  algorithms  and  processes,  the  system  designer  needs 
specific  tests  to  untangle  the  effectiveness  of  any  individual  component.  The  development 
of  a  MSDF  performance  evaluation  methodology  is  thus  one  aspect  of  the  current  research 
activity  at  DREV.  A  results  analysis  module  implementing  this  methodology  in 
CASE_ATTI  is  also  under  development.  It  will  comprise  a  set  of  computer  tools 
implemented  in  CASE_ATTI  to  help  the  MSDF  designer  in  his  assessment  of  the 
performance  of  the  algorithms  and  techniques.  These  tools  will  support  a  tracking  statistic 
compilation  mechanism,  the  output  of  performance  results  in  summary  tables  and  listings, 
the  plotting  of  statistics,  etc.  The  results  will  be  presented  in  a  user-friendly  manner  to  the 
operator  of  the  simulation  environment. 

Currently,  the  results  analysis  module  simply  comprises  a  sophisticated  graphics 
module.  The  purpose  of  this  module  is  to  aid  in  the  evaluation  of  the  tracking  algorithms  by 
showing  images  of  the  true  target  positions,  measurements,  clutter,  track  positions,  and 
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track  measurement  gates  generated  by  the  other  modules  (Refs.  14-16).  It  provides  for  a 
global  view  of  the  situation  and  allows  a  quick  assessment  of  the  tracking  performance. 
The  graphical  user  interface,  shown  on  Figs.  9-11,  has  been  designed  to  be  interactive  and 
user  friendly.  It  enables  the  user  to  zoom  into  specific  areas,  select  relevant  information, 
rotate  the  scene,  and  animate  the  simulation  through  a  user  specified  time  window. 

Both  a  three-dimensional  perspective  view  and  a  two-dimensional  radar- like  view 
are  provided.  The  radar  view  also  supports  both  Cartesian  and  polar  axes.  A  set  of  printed 
examples  of  the  graphics  and  user  interface  are  shown  in  Figs.  9  through  11. 

3.7  Simulation  Manager 

The  CASE_ATTI  manager  is  an  interface  built  on  top  of  the  simulation  software.  Its 
main  purpose  is  to  allow  the  user  easy  access  to  the  simulation  environment  (Refs.  14-18). 
It  allows  the  user  to  run  or  modify  an  existing  scenario,  or  to  create  a  new  one. 

In  its  present  form,  the  manager  consists  of  one  main  menu,  on  which  the  user  is 
presented  with  a  number  of  options.  From  this  main  menu  the  user  is  given  different  levels 
of  access  to  the  components  of  the  scenario.  Each  component  is  stored  in  a  particular 
format  and  has  its  own  specific  parameters.  When  the  user  makes  a  choice  in  the  main 
menu,  these  specific  parameters  are  automatically  displayed  in  the  specific  editor  for  that 
particular  component.  Within  this  editor  existing  components  may  be  displayed  and/or 
altered,  new  components  may  be  build  and  old  components  may  be  deleted. 

The  manager  also  contains  two  graphical  editors,  one  for  the  sensor  data  generation 
scenario  and  one  for  the  tracking  module  scenario  (Ref.  18).  The  sensor  module  scenario  is 
used  to  define  how  the  targets,  platforms  and  sensors  interact.  The  tracking  module 
scenario  defines  how  the  data  from  the  different  sensors  is  processed  and  fused.  Within 
both  of  these  two  graphical  editors,  the  user  is  presented  with  a  graphical  display  of 
connected  icons  (similar  to  the  tree  shown  in  Fig.  6)  that  illustrates  the  overall  scenario. 
This  greatly  facilitates  the  design  and  editing  of  the  different  simulation  scenarios.  The  non- 
graphical  component  editors  can  also  be  accessed  through  the  individual  text  icons  to  alter 
the  configuration  of  the  sensors,  platforms,  targets,  tracking  connections,  and  trackers. 

Besides  the  editors,  the  manager  contains  code  that  implements  an  interface 
allowing  the  user  to  choose  a  scenario  (i.e.,  data  generation  and  tracking)  to  be  run. 
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4.0  MSDF  FOR  THE  CANADIAN  PATROL  FRIGATE 

Most  of  the  current  research  in  MSDF  is  dedicated  to  the  development  and 
application  of  new  techniques,  but  little  has  been  performed  to  determine  how  well  such 
methods  apply  to  a  practical  system.  The  CPF  is  a  very  interesting  platform  for  MSDF 
application.  In  this  chapter  we  discuss  an  ongoing  study  making  use  of  the  CASE_ATTI 
system  to  support  the  development  of  MSDF  concepts  that  could  apply  to  the  current  CPF 
sensor  suite,  as  well  as  its  anticipated  upgrades  (i.e.,  MFR,  IRST,  CANEWS  2),  in  order 
to  improve  its  AWW  performance  against  the  predicted  future  threat.  The  study  aims  to 
identify  and  develop  techniques  for  combining  Radars/EO/ESM  data,  and  to  evaluate  the 
real  benefits  of  the  combination.  It  will  be  conducted  using  mainly  simulations  and,  where 
applicable,  pertinent  experimental  data.  Two  major  aspects  need  to  be  addressed  for  this 
application:  first,  the  representation  of  the  actual  CPF  sensor  suite  to  establish  its  baseline 
performance,  and  second,  the  quantification  of  the  performance  improvements  gained  when 
using  an  upgraded  sensor  suite  combined  with  advanced  MSDF  concepts.  These  two 
aspects  are  discussed  in  more  depth  below.  Since  this  activity  is  only  at  a  very  early  stage, 
the  emphasis  is  given  in  this  document  to  the  incremental  approach  that  will  be  followed 
and  to  the  criteria  that  will  be  used  to  evaluate  the  performance  and  quantify  the 
improvements.  Actual  results  will  be  published  in  a  subsequent  document. 

4.1  Establishing  the  CPF  Baseline  Performance 

The  definition  of  the  CPF  baseline  performance  for  this  study  comprises  two  related 
aspects.  Firstly,  the  performance  of  the  current  sensors  operating  in  a  stand  alone  mode  is 
evaluated.  Secondly,  the  global  performance  of  the  complete  sensor  suite  is  evaluated 
taking  into  account  the  limited  integration  that  is  performed  within  the  current  CPF 
Command  and  Control  System  (CCS).  In  both  cases,  it  is  assumed  that  the  sensors  are 
performing  in  accordance  with  their  specifications.  It  is  out  of  the  scope  of  this  project  to 
verify  if  the  sensors  meet  their  specifications. 

The  current  AWW  sensor  suite  of  the  CPF  comprises  the  SPS-49  long  range  2-D 
radar,  the  Sea  Giraffe  medium  range  2-D  radar,  the  CANEWS  ESM  and  the  Separate  Track 
and  Illumination  Radar  (STIR).  The  performance  of  this  suite  of  sensors  may  be  assessed 
by  flying  known  targets  on  predetermined  trajectories  and  measuring,  as  an  example, 
detection  ranges  and  tracking  performance  for  each  sensor  of  interest  and  for  the  CCS  track 
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management  module.  However,  this  method  is  time-consuming  and  costly.  The  approach 
we  propose  privileges  simulations.  It  is  cheaper  and  faster  than  experimental  methods  and 
permits  the  repetition  of  tests  under  simulated  conditions  which  may  be  difficult  to  obtain  in 
practice,  or  for  which  one  would  have  to  wait  for  a  very  long  time  for  a  natural  occurrence. 

To  establish  the  baseline  performance  of  the  current  sensor  suite,  the  detection, 
measurement  generation  and  tracking  behavior  of  each  sensor  must  be  adequately 
simulated.  In  terms  of  target  detection,  the  simulation  must  not  only  account  for  the 
sensor's  design  parameters,  but  also  for  a  number  of  other  factors.  In  most  cases,  the 
simple  radar  equation  based  on  free-space  propagation  yields  far  from  accurate  results  and 
must  be  modified  to  account  for  multipath,  ducting  and  other  effects.  A  representation  of 
the  effect  of  the  receiver  front-ends,  signal  and  data  processing  of  each  sensor  is  necessary. 

The  surveillance  radar  model  used  in  this  study  takes  into  account  all  aspects  of  the 
radar-environment-target  chain  (Ref.  25).  As  such,  the  model  is  sophisticated  and  a 
validation  of  its  behavior  must  be  performed  before  the  baseline  performance  can  be 
evaluated.  Based  to  a  large  extent  on  the  available  literature  and  on  relevant  experience  and 
studies  in  the  field,  many  aspects  of  radar  behavior  are  well  known  and  have  been 
validated.  Thus  the  validation  of  the  surveillance  radar  model  is  undertaken  by  first 
comparing  it  with  existing  and  accepted  radar  simulations  such  as  CARPET  (Ref.  28)  and 
Rohan  (Ref.  29)  when  it  is  possible  to  find  commonality.  Obviously,  this  validation  is 
different  from  a  shipboard  evaluation  against  live  data  in  a  very  well  controlled 
environment,  but  it  presents  some  real  advantages  in  terms  of  cost  and  this  is  an  important 
intermediate  step  before  implementing  or  acquiring  systems.  However,  the  next  validation 
step  should  be  with  trial  data. 

The  surveillance  radar  models  used  in  this  study  allow  the  generation  of 
measurements,  as  well  as  a  representation  of  the  tracking  performed  inside  the  sensors.  As 
a  result,  the  simulated  data  are  very  close  to  the  outputs  of  the  SPS-49  and  Sea  Giraffe. 
This  represents  an  original  novelty  of  our  simulation  environment.  Conventional  radar 
simulations  such  as  CARPET  are  not  fully  suitable  for  sensor  fusion  studies  mainly 
because  of  this  requirement  for  measurement  generation  and  data  processing.  CARPET,  for 
example,  only  gives  plots  of  different  parameters  of  the  radar  detection  aspects. 
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The  STIR  fire-control  radar  is  simulated  at  the  same  level  of  detail,  considering  the 
same  environmental  effects.  An  existing  Seaborne  Fire  Control  Radar  (SEFCOR)  (Ref.  30) 
simulation  of  a  pencil-beam  monopulse  tracking  radar  is  going  to  be  modified  and  adapted 
to  model  the  STIR.  To  complete  the  representation  of  the  suite  of  sensors  it  is  required  to 
provide  the  CASE_ATTI  system  with  an  ESM  (CANEWS)  simulation  capability.  For 
example,  this  could  be  accomplished  by  taking  advantage  of  two  products  developed  by 
Lockheed  Canada:  "Lockheed  Canada  Electronic  Warfare  Environmental  Simulator 
(LEWES)"  (Ref.  31)  and  "LC2000  ESM  system"  (Ref.  32).  The  LEWES  system  provides 
a  scenario  generator  software  capability,  while  the  LC2000  ESM  system  provides  an  ESM 
data  processor  software  capability.  The  combined  software  packages  can  be  used  to 
simulate  an  ESM  system.  However,  this  simulation  would  not  be  integrated  per  se  into 
CASE_ATTI;  only  the  ESM  output  data  would  be  integrated.  The  Lockheed's  software 
packages  would  be  modified  to  represent  CANEWS  capabilities,  and  to  render  the  ESM 
simulation  compatible  with  the  CASE_ATTI  environment. 

The  baseline  performance  will  be  evaluated  against  the  predicted  future  threat.  More 
precisely,  all  performance  evaluations  will  be  against  the  AWW  mission  and  threat 
requirements,  including  maneuvering  targets  and  if  possible  ECM  conditions,  which  have 
recently  been  specified  for  the  Canadian  Navy.  The  environmental  scenarios  to  be  used  will 
be  those  developed  by  DREV  for  the  NATO  Anti  Air  Warfare  System  (NAA WS)  program. 
An  appropriate  methodology  is  currently  being  defined  for  MSDF  algorithm  performance 
evaluation.  This  is  a  complex  issue  because  of  the  diversity  of  aspects  involved.  The 
method  to  be  used  needs  to  handle  the  ambiguities  that  arise  in  modern  multiple  sensor, 
multiple  target  tracking  problems. 

On  one  hand,  evaluating  the  performance  of  tracking  algorithms  is  straightforward 
in  a  clutter-free  environment  of  few,  widely  spaced  targets.  In  this  sparse  environment,  a 
track  is  consistently  updated  with  measurements  from  the  same  target.  The  track,  or  state 
estimate,  is  then  assigned  and  compared  with  the  true,  non  ambiguous  target  state.  On  the 
other  hand,  performance  evaluation  is  complex  in  a  dense  multiple  target  environment  with 
clutter,  false  alarms  and  unresolved  closely  spaced  objects,  because  of  ambiguities  that 
create  confusion  about  which  target  goes  with  a  track  (Ref.  33).  This  is  a  fundamental 
problem  in  evaluating  multiple  target  tracking  (MTT)  algorithms  that  is  not  encountered  in 
performance  evaluations  with  only  a  single  object.  In  this  case,  a  track  is  not  consistently 
updated  with  measurements  from  the  same  target  because  some  sensor  observations  of 
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other  targets,  clutter,  or  false  alarms  will  be  incorrectly  associated  with  the  track  and  some 
sensor  observations  associated  with  the  track  will  be  unresolved  closely  spaced  objects. 
Hence,  the  source  of  the  measurements  in  a  track  will  not  provide  a  clear  indication  of  a 
single  target,  thus  confusing  which  track  is  to  be  compared  with  the  true  state  of  a  target. 
Furthermore,  in  a  dense  target  environment,  there  may  be: 

•  missed  tracks:  targets  without  tracks 

•  false  tracks: 

-  redundant  tracks:  more  than  one  track  for  one  target 

-  spurious  tracks:  tracks  for  no  target  whatsoever 

-  lost  tracks:  once  valid  tracks  that  become  spurious 

The  performance  evaluation  methodology  must  accommodate  all  tracks,  those  for 
targets  of  interest  and  those  due  to  background  clutter  and  other  objects  that  are  not  of 
interest.  The  false  and  missed  tracks  should  be  identified  and  counted  in  addition  to 
resolving  the  ambiguities  for  the  valid  tracks.  Even  with  only  one  target  of  interest, 
persistent  clutter  points  can  create  objects  in  the  field  of  view  that  may  have  to  be  treated  as 
multiple  targets  by  the  tracking  algorithms.  Most  of  these  apparent  targets  should  eventually 
be  identified  as  stationary  objects.  However,  they  can  be  close  to  targets  of  interest  and 
thus  require  MTT  algorithms. 

A  two-step  approach  is  thus  necessary  for  MTT  performance  evaluation.  One  first 
needs  to  relate  targets  to  tracks.  Then,  after  tracks  and  truth  have  been  associated,  one  can 
evaluate  performance  criteria  for  the  two  main  functions  of  a  MTT  algorithm:  data 
association  and  state  estimation.  Measures  of  sensor  suite  performance  such  as  detection 
range,  firm  track  range,  transition  time  from  first  detection  to  firm  track,  track  maintenance, 
track  purity,  false  tracks,  track  accuracy,  and  credibility  of  the  filter  calculated  covariance 
are  then  employed. 

4 . 2  Advanced  Sensors  and  MSDF  Concepts  for  Performance  Improvement 

The  Canadian  Navy  is  planning  to  upgrade  the  CPF  sensor  suite.  However,  the 
development  and/or  acquisition  of  advanced  AWW  sensors,  although  necessary,  may  not 
be  sufficient  for  providing  the  required  protection  for  ships  against  the  anticipated  future 
threats.  The  simple  interfacing  of  these  components  is  not  enough  because  such 
independent  AWW  elements  are  seldom  used  in  a  coordinated  manner,  which  typically 
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leads  to  a  confusing  and  time-late  decision  environment  for  the  ship's  commander.  Hence, 
the  effectiveness  of  the  AWW  system  is  not  completely  determined  by  the  capabilities  of  the 
AWW  sensor  suite  alone,  but  also  by  the  effectiveness  of  the  system  integration  which 
must  focus  on  cooperative,  synergistic,  and  efficient  utilization  of  all  of  the  AWW  sensors. 

In  that  context,  an  incremental  approach  has  been  chosen  to  demonstrate  how  the 
performance  of  the  CPF  sensor  suite  can  be  improved  using  an  upgraded  sensor  suite 
combined  with  advanced  MSDF  concepts.  The  idea  is  to  compare  alternative  methods 
against  a  common  problem  and  to  evaluate  the  results  with  respect  to  the  baseline 
performance.  The  first  step  is  to  allow  minor  modifications  to  the  existing  system  such  that 
the  current  tracking  algorithms  for  each  sensor  taken  individually  can  be  improved  with 
advanced  techniques,  and  sensor  data  fusion  can  be  used  within  the  CCS.  This  is 
accomplished  within  the  CASE_ATTI  system.  CASE_ATTI  allows  the  possibility  of  trying 
all  kinds  of  tracking  algorithms  as  well  as  assessing  the  performance  of  various  types  of 
fusion  architecture.  Any  resulting  performance  improvements  with  respect  to  the  baseline 
performance  will  be  quantified. 

The  second  step  is  to  add  an  Infrared  Search  and  Track  (IRST)  simulation  to  the 
current  representation  of  the  CPF  sensor  suite.  The  required  MSDF  techniques  and 
algorithms  to  support  this  addition  to  the  sensor  suite  will  be  identified  and  developed.  An 
IRST  model  (Ref.  26),  that  was  developed  during  NAAWS,  is  being  modified  to  take  into 
account  recent  developments,  as  well  as  the  need  to  represent  a  data  processing  capability 
inside  the  IRST.  The  performance  obtained  through  MSDF  for  the  modified  sensor  suite 
will  be  evaluated  and  any  resulting  improvements  will  be  quantified. 

The  last  step  is  to  further  modify  the  current  CPF  sensor  suite  by  replacing  the 
STIR  and  the  Sea  Giraffe  simulations  with  a  Multi-Function  Radar  (MFR)  model,  and  by 
upgrading  the  CANEWS  ESM  simulation.  The  MSDF  algorithms  and  techniques  required 
for  the  integration  of  this  upgraded  sensor  suite  will  be  identified  and  developed.  The  level 
of  simulation  required  to  represent  the  MFR  functions  needs  to  be  identified.  A  starting 
point  may  be  the  model  (Ref.  34)  developed  under  NAAWS.  The  ESM  simulation  will  be 
modified  to  account  for  anticipated  CANEWS  2  capabilities.  Again,  any  resulting 
performance  improvements  will  be  quantified. 
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5.0  CONCLUSION 

Given  that  it  is  a  critical  issue  for  the  evolution  of  naval  C2,  there  are  multiple 
ongoing  research  activities  at  Defence  Research  Establishment  Valcartier  (DREV)  on  local 
area  Multi-Sensor  Data  Fusion  (MSDF)  for  naval  applications  afloat. 

A  broad  spectrum  of  tools  could  potentially  be  used  to  support  MSDF  studies.  This 
spectrum  ranges  from  using  very  simple  computer  simulations  supporting  rigorous 
mathematical  analyses  to  actually  testing  prototypes  during  live  military  exercises. 
Generally,  there  are  tradeoffs  in  selecting  one  approach  over  the  other.  It  was  decided  to 
employ  high-fidelity  simulations  for  the  MSDF  project  at  DREV.  The  CASE_ATTI 
(Concept  Analysis  and  Simulation  Environment  for  Automatic  Target  Tracking  and 
Identification)  system  built  to  support  theoretical  studies  on  MSDF  was  described  in  this 
document.  It  is  a  highly  modular,  structured,  and  flexible  simulation  environment 
providing  the  algorithm-level  test  and  replacement  capability  required  to  study  and  compare 
the  technical  feasibility,  applicability  and  performance  of  advanced,  state-of-the-art  MSDF 
techniques. 

Algorithm-level  testbeds  such  as  CASE_ATTI  are  becoming  necessary  to  efficiently 
study  MSDF  concepts  that  could  be  used  to  fulfill  the  Canadian  Forces  requirements  in  the 
selection  of  integrated  surveillance  and  tracking  systems,  and  in  the  optimization  of  their 
operation  for  better  performance.  In  this  document  we  discussed  the  use  of  the 
CASE_ATTI  system  to  support  the  development  of  MSDF  concepts  that  could  apply  to  the 
current  CPF  sensor  suite,  as  well  as  its  anticipated  upgrades,  in  order  to  improve  its  AWW 
performance  against  the  predicted  future  threat.  The  establishment  of  the  CPF  sensor  suite 
baseline  performance  along  with  an  incremental  approach  to  demonstrate  how  this 
performance  can  be  improved  using  an  upgraded  sensor  suite  combined  with  advanced 
MSDF  concepts  were  discussed. 

The  tool  sets  and  trial  data  sets  for  supporting  MSDF  R&D  are,  like  the  MSDF 
process  and  its  algorithms,  only  beginning  to  mature.  Modern  designs  of  true  testbeds 
permitting  flexible  algorithm-level  test-and-replace  capability  for  scientific  experimentation 
are  beginning  to  appear  and  are,  at  least,  usable  within  certain  subsets  of  the  Canadian 
MSDF  community.  These  testbed  environments  offer  not  only  an  economical  basis  for  the 
testing  of  MSDF  techniques  and  algorithms,  but,  more  importantly,  a  means  to  achieve 
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optimality  or  at  least  properly  satisfying  performance  requirements  of  candidate  methods 
under  test. 

Motivated  in  part  by  the  need  for  continuing  maturation  of  the  MSDF  process  and 
the  amalgam  of  techniques  employed,  and  in  part  by  expected  reductions  in  the  defence 
research  budget,  the  data  fusion  community  should  consider  strategies  for  the  sharing  of 
resources  for  R&D.  Plans  to  share  demonstrator  testbeds  on  a  broader  basis  are  indeed 
beginning  to  appear.  The  possibility  to  use  CASE_ATTI  to  support  the  research  performed 
at  DREO  for  the  computation  of  the  tactical  picture  in  the  context  of  the  North  Warning 
System  (NWS)  is  currently  being  seriously  studied.  In  the  coming  era  of  very  tight  defense 
research  budgets,  algorithm-level  testbeds  should  enter  a  national  inventory.  For  example, 
CASE_ATTI,  as  an  available  product,  could  also  play  an  important  role  in  the  third  phase 
of  the  D6195/ASCACT  (Advanced  Shipboard  Command  and  Control  Technology)  project, 
to  become  a  component  of  a  more  global  C2  testbed. 
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